Fixes #30557
Fixes #29040

Both halves of the "silent no-op" complaint in #27889: the server declares what each resource can
deliver and rejects the rest, and the alert builder offers only what the server declares. They ship
together so the UI can never present a combination the API will refuse.

Problem

An alert can be saved with event types its resource can never produce, and it then delivers nothing
with no error and no empty state. Reproduced on main:

alert a27889gtsuggestion1785226866
  resource: glossaryTerm
  rule:     matchAnyEventType({'suggestionCreated','suggestionAccepted'})
  events:   total 0, pending 0, successful 0, failed 0

Two blind spots:

• Nothing declares what a resource emits. GET /v1/events/subscriptions/notification/resources
  returned only name, supportedFilters, supportedActions, containerEntities, so the builder
  falls back to the whole 26-value EventType enum.
• Save-time validation checks filter names, not values. AlertUtil.getFilterRule rejects a
  filter the resource does not support, but never inspects the arguments inside it.

What each resource can actually deliver

Derived from the emitters rather than from the enum:

Never declared, because nothing can deliver them: entityNoChange, taskCreated, taskUpdated,
the five suggestion*, userLogin, userLogout.

Three of those deserve a note, since they are easy to assume otherwise:

• entityFieldsChanged is not generic. Only usage reporting emits it (UsageRepository:121-125), for exactly five entities. QueryRepository also emits it, but ChangeEventHandler:57-59 drops every query and workflow event before insert.
• userLogin / userLogout never reach change_event. AuditLogRepository.writeAuthEvent builds a ChangeEvent, but write() only inserts an AuditLogRecord. Verified on a running instance: 22 logins, all in audit_log_event, none in change_event.
• entityNoChange is a sentinel that ChangeEventHandler:77 explicitly skips.

Changes (server)

• filterResourceDescriptor.json gains supportedEventTypes, so the descriptor already served at /notification/resources now carries the declaration and the UI needs no new endpoint.
• New ResourceEventTypes encodes the table above: two family constants, a usage-resource set, explicit entries for all, conversation and task, and the entity+thread default for everything else. EventSubscriptionResource.getNotificationsFilterDescriptors() attaches it where it already maps filter names onto rules.
• AlertUtil.validateAndBuildFilteringConditions looks the descriptor up once and hands it to both gates: the existing filter-name check, and the new event-type value check that reads descriptor.getSupportedEventTypes() and throws BadRequestException naming the resource and the value, with the message next to resourceTypeNotFound in CatalogExceptionMessage.

The input descriptor (EventSubResourceDescriptor.json) is deliberately untouched. The declaration is
derived rather than declared, following ResourceRegistry, which answers the same question for
authorization: a common base plus per-resource specifics plus an all entry, computed in Java, served
to a builder UI at /v1/policies/resources and enforced by PolicyEvaluator. As there, the rules are
a producer with a single consumer and every reader goes through the descriptor, so AlertUtil never
calls ResourceEventTypes directly. Twenty-eight hand-written lists is also how the existing
descriptor drifted: it still carries the dead tagCategory and lacks its replacement classification.

Observability is unaffected: EntityObservabilityFilterDescriptor.json offers no filterByEventType.

Changes (UI)

AlertsUtil.tsx built the Event Type field from the whole EventType enum
(getSelectOptionsFromEnum(EventType)), regardless of the selected resource. It now uses the
resource's supportedEventTypes, falling back to the enum when a resource declares none, which
keeps a newer UI working against an older server and leaves observability alone (its descriptors
carry no filterByEventType).

supportedEventTypes is threaded exactly like the existing containerEntities: derived where the
descriptor is already looked up (AddNotificationPage, and AlertConfigDetails for view mode),
passed into ObservabilityFormFiltersItem, and forwarded through getConditionalField into
getFieldByArgumentType. One new pure helper, getSelectOptionsFromValues, sits beside
getSelectOptionsFromEnum and uses the same startCase label transform, which keeps the Playwright
selectors ([title="${startCase(eventType)}"]) and the view-mode labels working.

No new i18n strings.

An alert saved before this change that stores a now-unadvertised value still shows it as a
removable chip, labelled with the raw value, so it can be cleared. Verified in the browser rather
than assumed.

Behaviour change worth noting in release notes

Enforcement is strict for create and update alike, for filters that include an event type. An
alert upgraded from an older release that includes a now-unreachable value (suggestionCreated,
taskResolved, …) must have that value removed before its next save; the 400 names it. The value was
already dead, so nothing that used to fire stops firing. #29039's migration clears those values
wholesale.

An EXCLUDE filter is left alone: excluding an event type the resource cannot produce is a harmless
no-op, not an alert that can never fire, so it is not worth blocking a save over.

Tests

• AlertsUtil.test.tsx: the field offers only the values it is given, and falls back to the whole enum when given none.
• ResourceEventTypesTest: per-resource assertions, plus an anti-drift test asserting that the union of every declared list and the never-deliverable set is exactly EventType.values(), so adding an enum value without deciding where it belongs fails the build.
• EventTypeValidationTest: the gate, including table accepting entityFieldsChanged while glossaryTerm rejects it, and an unknown string being rejected rather than throwing.
• EventSubscriptionResourceIT: 400 on an unreachable value naming it, a reachable value still saving, and /notification/resources serving supportedEventTypes over the wire.

Verified on a local deploy

glossaryTerm  [entityCreated, entityUpdated, entitySoftDeleted, entityDeleted, entityRestored,
               threadCreated, threadUpdated, postCreated, postUpdated]
conversation  [threadCreated, threadUpdated, postCreated, postUpdated]

glossaryTerm + suggestionCreated    -> 400 "Resource glossaryTerm does not produce event type
                                            suggestionCreated, so an alert filtering on it can never fire"
glossaryTerm + entityFieldsChanged  -> 400
glossaryTerm + threadCreated,postCreated -> 201
table + entityFieldsChanged              -> 201

And in the alert builder, on a Glossary Term alert: searching the Event Type dropdown for
"sugg" or "fields" returns No data, while "thread" offers Thread Created and Thread Updated.
The pre-existing alert that stores suggestionCreated still renders it as a removable chip.

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  E[Event emitters] --> M[ResourceEventTypes mapping]
  M --> D[Notification resource descriptor]
  D --> UI[Alert builder options]
  D --> V[AlertUtil save-time validation]
  UI --> S[Subscription request]
  S --> V
  V -->|supported| P[Persist subscription]
  V -->|unsupported| B[400 Bad Request]

_{Reviews (8): Last reviewed commit: "Merge branch 'main' into fix/alert-suppo..." | Re-trigger Greptile}